Mapping of packets to pdp contexts in multisession connection

ABSTRACT

Routing packets belonging to different quality of service flows in a packet data network system is described. For each application initiated by a subscriber equipment with an associated quality of service flow in a multi-session connection settings of a network node hosting the application are obtained. From the obtained settings configuration information are determined and packets are routed from the network system to the subscriber equipment for each initiated application in accordance with the configuration information.

FIELD OF THE INVENTION

[0001] The present invention relates to the dynamic configuration of auser equipment or the applications inside the user equipment capable ofconnecting to a variety of external networks (e.g. Internet, Intranet)through an access technology supporting multiple QoS flows. Theinvention is particularly relevant for the mapping of data packets toPDP contexts for GPRS (General Packet Radio Service) subscribers havingmultiple sessions and applications active simultaneously.

BACKGROUND OF THE INVENTION

[0002] Typical networks such as an Internet network may be accessedthrough a variety of ways (GPRS, WLAN, ADSL modem, etc.). In addition,many access technologies support multiple QoS flows (GPRS, ADSL, RSVP,etc.). For the same time, the same user equipment is often used toaccess different networks. A typical illustration is a GPRS networkwhere a user equipment may be connected to the Internet or an Intranetusing different Access Points. GPRS is the packet technology used in GSMand in UMTS (using WCDMA (Wideband Code Division MultipleAccess)radio)). In GPRS, each QoS flow is associated to a PDP context(logical connection from user equipment to external network).

[0003] In a PDP (Packet Data Protocol) Context Activation Procedure asshown in FIG. 1, an MS (Mobile Station) sends an Activate PDP ContextRequest message comprising PDP Type, PDP Address, APN (Access PointName) and QoS (Quality of Service) Requested to an SGSN (Serving GPRSSupport Node) in a PLMN (Public Land Mobile Network). QoS Requestedindicates the desired QoS profile. The SGSN validates the Activate PDPContext Request optionally using PDP Type, PDP Address and APN.

[0004] If a GGSN (Gateway GPRS Support Node) address can be derived, theSGSN sends a Create PDP Context Request message comprising PDP Type, PDPAddress, APN and QoS Negotiated to the affected GGSN. The GGSN may usethe APN to find an external network. A Selection Mode indicates whethera subscribed APN was selected, or whether a non-subscribed APN sent bythe MS or a non-subscribed APN chosen by the SGSN was selected. The GGSNmay use the Selection Mode when deciding whether to accept or reject thePDP context activation. For example, if an APN requires subscription,then the GGSN is configured to accept only the PDP context activationthat requests a subscribed APN as indicated by the SGSN with SelectionMode. The GGSN creates a new entry in its PDP context table and createsa Charging Id. The new entry allows the GGSN to route PDP PDUs (PacketData Units) between the SGSN and the external PDP network and to startcharging. The GGSN returns a Create PDP Context Response messagecomprising PDP Address, QoS Negotiated and Charging ID to the SGSN.

[0005] If QoS Negotiated received from the SGSN is incompatible with thePDP context being activated, then the GGSN rejects the Create PDPContext Request message.

[0006] The SGSN returns an Activate PDP Context Accept message to theMS. The SGSN is now able to route PDP PDUs between the GGSN and the MSand to start charging.

[0007] GPRS can support different QoS flows, each corresponding to a PDPcontext, for a unique PDP address (e.g. Ipv4 or Ipv6 address). In 3GPPRelease 99 the QoS mechanism uses a set of filters called Traffic FlowTemplate (TFT) and information in the IP header, such as Type of Service(ToS) field or UDP (User Datagram Protocol) port number in order todetermine to which PDP context an IP packet belongs.

[0008] The MS maps uplink packets to the proper PDP context, and GGSNmaps downlink packets to the proper PDP context using TFT. It is to benoted that the MS configures the GGSN TFT.

[0009] While such QoS mechanism allows to differentiate traffic, it maynot always be easy to use for various reasons:

[0010] applications do not always use fixed port numbers,

[0011] end-to-end encryption may render the UDP port number inaccessiblefor the GGSN,

[0012] ToS values are selected by the operator, so an application mayhave different ToS values in different networks, and/or

[0013] ToS values may be changed by edge routers at the point ofinterconnection between two ISPs (Internet Service Providers).

[0014] A typical application example is an H323 call. Relying on theport number is not useful since some H323 family protocols e.g. H245 usedynamic port. Using the port number will be just impossible ifencryption is used.

[0015] Usually, the end point of an IP connection of the user equipmentis a server in an IP network, which is controlled by the operator of theIP network, for example a Call Server, or the end point is a server inthe Internet or Intranet, which is not controlled by the IP networkoperator. However, communication may also be established between twouser equipments (e.g. VOIP call), connected through different operators'networks.

[0016] Hence, the general problem is how to properly configure QoS forapplications which may connect through different access and to differentnetworks, in particular, the QoS parameters used by the accesstechnology, the filter used to select the proper QoS flow, and QoSparameters (e.g. ToS) used in the network where the connection isestablished. An additional problem is how to set filters forapplications which do not use fixed port number, or for which the portnumber cannot be read due to encryption. A further problem is that ToSsetting is most often proprietary.

SUMMARY OF THE INVENTION

[0017] It is therefore an object of the present invention to solve theabove-mentioned problems and to provide QoS related configuration forevery application even if encryption is used.

[0018] According to the present invention, this object is achieved by asystem according to claim 1. Moreover, the object is achieved by aconfiguration device according to claim 14. In addition, the object isachieved by a method according to claim 19.

[0019] According to the present invention, a packet data network systemfor routing packets belonging to different quality of service flowscomprises a subscriber equipment for initiating applications withassociated quality of service flows in a multi-session connection. Thesubscriber equipment may comprise a laptop or the like and a “modem” oraccess device (e.g. ADSL modem or mobile station) for transmitting datapackets to a packet data network like an operator IP network. Thesubscriber equipment may also integrate application and modem in thesame device such as a Nokia communicator.

[0020] It is important to distinguish two cases:

[0021] the application is tightly integrated to the access technology,so that it can indicate the QoS needed and the QoS flow that it shoulduse. This is typically but not necessarily the case of an integrateddevice.

[0022] the application is not tightly integrated to the accesstechnology, so that it may indicate the QoS needed using generic API,and cannot directly identify the QoS flow that is should use. Insteadthe modem needs to map the traffic received from different applicationsto different QoS flows using its own filters. This is typically but notnecessarily the case of a separated device.

[0023] The system further comprises a configuration device like aconfiguration server (e.g. policy server) which may be located in theoperator IP network. The configuration device obtains, for eachinitiated application, type of service information of a network nodehosting the application, such as an operator application server, mediagateway, H323 gatekeeper, laptop, etc. Then, the configuration deviceprovides the configuration information to the subscriber equipment. Thisinformation is derived from the obtained type of service information andpossibly from the operator policy. This information includes QoSparameter defining QoS flow (e.g. GPRS QoS profile), filters for uplinkand downlink (e.g. TFT), and parameters to be used by the application(ToS or port number).

[0024] The system further comprises a gateway node, like a GGSN,connecting the access technology to the operator IP network, forexchanging packets between the network and the subscriber equipment.This gateway should select the proper QoS flow for each applicationusing filters using for example ToS field of incoming packets. Thesubscriber equipment uses the obtained configuration information to setthe filters and the associated quality of service flow in the gatewaynode. The gateway node is able to route the packets into the proper QoSflow on the basis of the filter set by the user equipment and the packetheader (e.g. ToS field). It should be noted that the User equipment setsthe filter in the gateway node because if dynamic configuration is notused, the application in the user equipment is the only entity capableof properly setting the filter. This is the case in GPRS where MS setsTFT. It is assumed that the same generic mechanism is kept with dynamicconfiguration, so that filters of the gateway node are set by the userequipment.

[0025] The type of service information (or other field used by thefilter) marked in the packets sent by an application may be determinedby an operator of the network hosting this application. In a preferredembodiment, this ToS is set by the same configuration device into thevarious applications. In this case the configuration device obtainsthese parameters directly. If the application is located in a differentnetwork connected through an edge router capable of changing the type ofservice information of the IP packets, the same configuration device mayconfigure the edge router and obtain type of service used by theapplication in the other network. The configuration device will thenknow with what type of service information the packet will be markedwhich belongs to a certain application arriving at the gateway node.

[0026] If the configuration device cannot configure the parameters setby the application directly (e.g. the application is not implementingdynamic configuration), the configuration device may further obtainsettings, such as Type of Service (ToS) information (i.e. DiffServcodepoints), of the application(s) in the subscriber equipment andprovide to the subscriber equipment the configuration information. Thisconfiguration information is preferably filters based on the type ofservice information and appropriate QoS parameters. This is illustratedin FIG. 2, where when knowing the settings of the application and theoperator policy (here Netscape and Q931 use interactive class, Emailuses background class and UDP/RTP uses conversational class), theconfiguration device can indicate the proper filters to the subscriberequipment (e.g. Mobile station). The subscriber equipment then uses theToS field of the IP packets coming from an application and the filter tomap this uplink packet into the appropriate QoS flow (e.g. PDP context).The subscriber equipment transmits packets to the network for eachinitiated application in accordance with the associated quality ofservice flow mapped in the subscriber equipment.

[0027] Further, in order to properly configure the Gateway (e.g. GGSN),the subscriber equipment may need to know the mapping for downlink. Thisset of filters (e.g. TFT) is first sent from the configuration device tothe subscriber equipment and then from the subscriber equipment to thegateway. The gateway is then able to transmit every downlink packet intothe right QoS flow.

[0028] The configuration device may further obtain setting informationin a variety of ways:

[0029] First, settings are often very static. For example, a certaintype of application uses a fixed UDP port. Some other application mayalways use same ToS information. In such case, the settings informationis just public knowledge.

[0030] In a second embodiment, the application may have configurablesettings. In this case, the operator may be able to provide thisconfiguration to the user. He may pre-configure it before selling theapplication to the user, or he may use remote configuration, or he mayhave an agreement with the Information Management (IM) department of acorporate who will install proper settings. This last case assumes thatthe corporate has a special agreement with the operator.

[0031] The present invention presents a method for dynamicallyconfiguring a user equipment and an application in the user equipment,so that packet traffic of the application is sent through proper QoSflow using appropriate QoS parameters. Packets are routed in the properQoS flow using filters. These filters use information contained in thepacket header such as ToS information for mapping packets to associatedQoS flows (e.g. PDP contexts). Thus, the level of QoS needed by anapplication is provided. The present invention provides means forconfiguring uplink and downlink filters and their associated QoS flowfor every application or protocol used by a user equipment.

[0032] In the following the present invention will be described by wayof preferred embodiments thereof with reference to the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0033]FIG. 1 shows a PDP Context Activation Procedure.

[0034]FIG. 2 shows a schematic block diagram of a network systemcomprising a configuration server according to the present invention.

[0035]FIG. 3 shows a system where a policy server uses COPS todynamically configure the user equipment.

[0036]FIG. 4 shows a system where a configuration server uses WAP todynamically configure the MS.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0037]FIG. 2 shows a network system according to GPRS. A Mobile Station(MS) to which a laptop can be connected can initiate multiple sessionsin order to use applications or protocols hosted in an operator IPnetwork by an operator application server, a media gateway and/or anH323 gatekeeper, for example. For each session a PDP context with arequested QoS is activated by the MS in an SGSN (not shown) towards aGGSN in the operator IP network. The GGSN then has to map downlinkpackets belonging to the different applications or protocols to theproper PDP contexts or QoS flows.

[0038] According to the present invention, a dedicated, network-specificconfiguration server keeps track of the ToS settings of applicationshosted within the network system.

[0039] According to an embodiment of the present invention, theconfiguration server knows how the laptop sets the ToS bits for everyapplication. The configuration server obtains its knowledge from thecorporate IT (Information Technology) staff, or from the software theoperator provides to the user (preferably remotely). In case of acommunicator like integrated MS, the operator knows the ToS setting fromthe mobile type or manufacturer and provides the knowledge to theconfiguration server.

[0040] According to another embodiment, the operator may be able toconfigure the mobile setting, i.e. the mapping between the applicationand the ToS bits. This could be done by using a default standard or anagreed standard.

[0041] The configuration server is provided with the ToS information ofthe applications hosted in the operator network. For example, theconfiguration server knows how the application server sets the ToS bits.This is a straightforward configuration if the application server isowned by the operator or an operator partner. The setting may also beknown if the application server is set up by corporate staff and theoperator has an agreement with the corporate. A particular importantapplication server is a Call Server which is foreseen to be managed bythe operator. The knowledge about the setting may also be derived fromdefault standard or agreed standard.

[0042] When the subscriber initiates a session in order to use anapplication hosted in the operator IP network shown in FIG. 2, theconfiguration server of this IP network provides the MS with ToSinformation of the application in order to inform the MS how it shouldconfigure its own TFT and the GGSN TFT. The operator may use MExE(Mobile application Execution Environment) to update MS configuration,i.e. mapping of ToS to PDP context. When the MS configures the TFT to beused in the GGSN for that session it is able to specify the correct ToSinformation and the GGSN can use the ToS information when routingpackets to several simultaneous sessions of the same subscriber.

[0043] Alternatively, the ToS information may be initially deliveredfrom the configuration server to the MS over a single-session connectionfrom the subscriber to the application when it is self-evident to theGGSN which PDP context to use.

[0044] In case there are EDGE routers that interfere with ToSinformation being passed, the configuration server application needs tobe aware of the nature of the interference and be able to counteractthis interference. In case of an operator's own edge router itsbehaviour can easily be known and counteracted by the configurationserver.

[0045]FIG. 2 shows an example of ToS settings and PDP context mappings.The configuration server knows the ToS settings of the laptop forNetscape (=ToS4), Email (=ToS3), Q931 (=ToS5) and User DatagramProtocol(UDP)/Real Time Protocol (RTP) (=ToS11) and provides these ToSsettings to the MS and informs the MS how to configure its TFT, i.e. howto map the uplink ToS to PDP context. As shown in FIG. 2, the MS mapsToS4 to PDP context 1 (interactive), ToS3 to PDP context 2 (background),ToS5 to PDP context 1 (interactive) and ToS11 to PDP context 3(conversational).

[0046] Moreover, the configuration server knows the ToS settings of theoperator application server (Netscape=ToS8), Email=ToS3) and the mediagateway (Q931=ToS7, UDP/RTP=ToS13), which host the initiatedapplications. The configuration server provides these settings to the MSand informs the MS how to configure the GGSN TFT, i.e. how to map thedownlink ToS to PDP context. The MS configures the GGSN TFT accordingly,so that the GGSN maps ToS3 to PDP context 2, ToS8 to PDP context 1,ToS13 to PDP context 3 and ToS7 to PDP context 1. Hence, the downlinkpackets are mapped by the GGSN to the same PDP context as thecorresponding uplink packets.

[0047] A different signaling flow showing how to configure the MobileStation is depicted in FIGS. 3 and 4.

[0048]FIG. 3 shows a PDP context activation where the GGSN checks theauthorization from a policy server using a COPS-pull request(communication 3 in FIG. 3). The COPS-pull request contains useridentity, user IP address, QoS requested, TFT, authorization token, anindication of intended use of the PDP context if available (e.g.signaling PDP context), MS capability and other relevant-parameters. Ifthe policy server authorizes the PDP context, the policy server sends aCOPS decision to the GGSN (communication 4 in FIG. 3) and may furthersend configuration information directly to the MS using COPS-push(communication 7 in FIG. 3). This configuration information contains alist of filter(s), and associated with every filter: Diffserv marking,UMTS QoS profile, TFT and APN. In addition, an application server IPaddress to be used by different applications may be sent. Note that APNmay be-set to wild card to indicate that any APN would be acceptable.This information is not limited to the configuration information neededby one application, but may cover all applications for which the MS hasrights and capabilities to handle. The capabilities are deduced from anew information element “MS capability” which is an addition to existingPDP context activation procedure proposed in this application. “MScapability” covers QoS support (maximum bit rate supported by the MS;list of traffic classes supported) and list of applications installed inthe MS. This information will be received by the MS.

[0049] The application server IP address (such as WAP Gateway addresscurrently hard-coded) may then be dynamically set in the MS.

[0050] In a first embodiment, the case in which an application is notconfigurable by the MS, i.e. typically implemented on a separate device,is described.

[0051] According to the first embodiment, the MS behaves in thefollowing way. If an uplink packet is received by the MS, the MS willfirst check it against the filter (e.g. UDP port 8080). The filterindicates to the MS with which Diffserv codepoints this uplink packet isto be marked and with which UMTS QoS profile it should be sent over theradio. The MS will then check whether a suitable PDP context exists(similar QoS and same PDP type, acceptable APN) to send the packetdirectly. If such a PDP context is found the packet is sent in this PDPcontext. If no suitable PDP context exists, the MS will activate asuitable PDP context. After the PDP context activation, the packet willbe sent in this PDP context. The PDP context may be deleted after notraffic has been sent during a certain time.

[0052] In a second embodiment, the case in which an application isconfigurable by the MS, i.e. typically implemented in the MS, isdescribed.

[0053] According to the second embodiment, the MS uses the configurationinformation received in communication 7 in FIG. 3 to configure theapplication. The application properly marks the IP packet based on themarking information sent in the COPS-push message. If the applicationneeds to send a packet, it first requests a PDP context activation withappropriate QoS, appropriate APN, and appropriate TFT.

[0054]FIG. 4 shows a system where a configuration server usesWAP-(Wireless Application Protocol)push to dynamically configure theapplication in the MS. WAP-Push includes in its addressing theapplication ID, and therefore is well suited to address an applicationdirectly.

[0055] When a PDP context is created, the GGSN sends to a configurationserver a RADIUS start accounting message (communication 3 in FIG. 4)containing user identity (e.g. IMSI, MSISDN), user IP address, QoSrequested, an indication of intended use of the PDP context if available(e.g. signaling PDP context), MS capability and other relevantparameters. When the PDP context will be deactivated a RADIUS stopaccounting message is also sent to the configuration server. Thereforethe configuration server is aware whether the MS is connected or not.

[0056] The configuration server sends an acknowledge message to the GGSN(communication 4 in FIG. 4) and further sends a WAP-push messagedirectly to the application(s) it needs to configure (communication 7 inFIG. 4). This message contains configuration information such as filter(mapping for uplink), Diffserv marking, UMTS QoS profile, TFT (mappingfor downlink), APN and application server IP address to be used by thisapplication.

[0057] While the invention has been described with reference topreferred embodiments, the description is illustrative of the inventionand is not to be construed as limiting the invention. Variousmodifications and applications may occur to those skilled in the artwithout departing from the true spirit and scope of the invention asdefined by the appended claims.

1. A packet data network system for routing packets belonging todifferent quality of service flows, the system comprising: a subscriberequipment for initiating applications with associated quality of serviceflows in a multi-session connection; a configuration device forobtaining, for each initiated application, settings of a network nodehosting the application, and for providing configuration informationbased on these settings to the subscriber equipment; and a gateway nodefor exchanging packets between the network system and the subscriberequipment; wherein the subscriber equipment is arranged to provide thegateway node with the configuration information; and the gateway node isarranged to route the packets in accordance with the configurationinformation.
 2. A system according to claim 1, wherein the configurationinformation comprises quality of service parameters defining quality ofservice flow.
 3. A system according to claim 1, wherein theconfiguration information comprises filters for uplink and downlink. 4.A system according to claim 1, wherein the configuration informationcomprises parameters to be used by the application.
 5. A systemaccording to claim 1, wherein the settings comprise type of serviceinformation.
 6. A system according to claim 1, wherein the configurationdevice is further arranged to derive the configuration information onthe basis of the operator policy.
 7. A system according to claim 1,wherein the needed quality of service flow is determined by theapplication directly.
 8. A system according to claim 1, wherein theconfiguration device is further arranged to obtain settings of thesubscriber equipment for each initiated application and to provideconfiguration information based on these settings to the subscriberequipment; and the subscriber equipment is arranged to transmit packetsto the network system for each initiated application in accordance withthe configuration information.
 9. A system according to claim 1, whereinthe settings of the network node hosting the application are determinedby an operator of the network node.
 10. A system according to claim 1,wherein the settings of an application are fixed.
 11. A system accordingto claim 1, wherein the settings of an application are determined by anoperator.
 12. A system according to claim 1, wherein, in case thegateway node is arranged to route the packets on the basis of thesettings of the hosting network node, the configuration device isarranged to provide the configuration information to the subscriberequipment over a single-session connection from the subscriber equipmentto the hosting network node.
 13. A system according to claim 1, furthercomprising: an edge network node capable of changing the settings of ahosting network node; wherein the configuration device is arranged toobtain settings of the edge network node and to provide configurationinformation based on the edge network node settings.
 14. A configurationdevice for supporting mapping packets to quality of service flows in apacket data network system, the device comprising: means for obtaining,for each application initiated by a subscriber equipment with anassociated quality of service flow in a multi-session connection,settings of a network node hosting the application; and means forproviding configuration information based on these settings to thesubscriber equipment enabling the subscriber equipment to map settinginformation to the associated quality of service flow.
 15. Aconfiguration device according to claim 14, further comprising means toderive the configuration information on the basis of the operatorpolicy.
 16. A configuration device according to claim 14, furthercomprising means to obtain settings of the subscriber equipment for eachinitiated application and to provide configuration information based onthese settings to the subscriber equipment for enabling the subscriberequipment to transmit packets to the network system for each initiatedapplication in accordance with the configuration information.
 17. Aconfiguration device according to claim 14, wherein, in case a gatewaynode is arranged to route packets on the basis of the settings of thehosting network node, the configuration device comprises means toprovide the configuration information to the subscriber equipment over asingle-session connection from the subscriber equipment to the hostingnetwork node.
 18. A configuration device according to claim 14, furthercomprising means to obtain settings of an edge network node capable ofchanging the settings of a hosting network node, and to provideconfiguration information based on the edge network node settings.
 19. Amethod of routing packets belonging to different quality of serviceflows in a packet data network system, the method comprising the stepsof: obtaining, for each application initiated by a subscriber equipmentwith an associated quality of service flows in a multi-sessionconnection, settings of a network node hosting the application;providing configuration information based on these settings to thesubscriber equipment; providing a gateway node for exchanging packetsbetween the network system and the subscriber equipment with theconfiguration information; and routing the packets in accordance withthe configuration information.
 20. A method according to claim 19,further comprising the steps of: obtaining settings of the subscriberequipment for each initiated application and providing configurationinformation based on these settings to the subscriber equipment; whereinpackets are transmitted from the subscriber equipment to the networksystem for each initiated application in accordance with theconfiguration information.